MAAP

COULD ALSO CREATE A FILTER TO CATCH ALL INSTANCES IN STORES AFFECTED BY A CHANGE NOT JUST FOR SPECIFICATIONED TYPE INSTANCES COULD RUN CUSTOM CODE OVER THEM

So could be automatic can discern changes from analysis of both specifications, then construct delta transformations between them. May also want different changes to the automatically discerned ones, so an addition of a new variable on the specification could be handled in many different ways, it could be set to the value of another variable, to a new value, the result of a custom function written at the time of question position

When are these updates performed? after code saving, after a coding session, manually, one some sort of initial program loading, upon loading of the individual data pieces, a combination of the aforementioned

So what are all the developer intended ways that a datas specification can change? q= Intention for the name to change w= attribute deletion e= attribute addition r= the type to change t= default value to change y= default factory to change u= the addition of a default value i= the removal of a default value o= the addition of a default factory p= the removal of a default factory

things to do to an instance as a result of intended actions

q-> Update the name, has to be done in a specific order to avoid potential clashes w-> remove that attribute ( notPresent) e-> Add that attribute, has to be done in a specific order to avoid potential clashes The value of that attribute should be that of the default factory if present, failing that the default value if present. If we develop a system of Describing default instance values for types then that should be used. Failing that then we should either prompt for a ( value, script) or set it to None depending on the context ( newlyPresent) r-> I imagine in some scenarios we would want to leave instances alone and in some we would want to update them. To update them, if we had a method of Checking if an object instance matches a certain complex type definition then we could check if the the attribute matches the new type and if not then we can assign a default value if one can be found, else we can use a prompt value, script, None t-> I dont think anything should happen here. ( varChange) Maybe one should have the option to take action, maybe i wish to update all instances which had the default value, maybe if this is occuring within an environment where we are prompting this is a desirable suggestion to present y-> unlike t we cant reliably detect data created by the factory and so we do nothing u-> All current instances would have then been created without a default value so nothing should be done i-> So instances created with the old default value may be wished to be updated, we can detect the old value and set it to the new one o-> All current instances would have then been created without a default factory so nothing should be done p-> unlike i, we cant detect the old value so nothing should be done

It seems as though the ability to control what is prompted would be useful Dont forget that we need to update not only the root of the saved data but also all contained data too

So list required bulk utilities and then list the ones used by each intended action response

So this list is constructed regardless of the need to update non root data

editing [ Change the name of an attribute at a specific path, Remove an attribute at a specific path, Add an attribute at a specific path with a specific value, Change the value of an attribute at a specific path to a specific value ] finding [ search for all instances of a specification where an attribute doesnt match a specific complex type definition - only possible once loaded into memory search for all instances of a specification where an attribute matches a specific value ] searching for all instances of a specification wouldnt work with a structure of saying attribute equals and would have to be The existing idea of finding data relies on finding specific data id items, granted we could find items which contain instances of a specification matching the requirements but we are also not in a position to return data about where those instances are in that datas tree which is nescessary, it doesnt seem like a good fit for this structure unless this method of working was implemented into the planned bulk action system, then the resultant updates of ( r, t, i)

Updating the value of an attribute at a path to a scripts value has to happen in python memory and so is not useful to have the store manage this

How does the order resolution work? Well we cant change a name to one which already exists There wont ever be a final state with clashing names So we can do all deletions first, then we can do replacements in the replacements we can ammass all pairs where replacement 0 has a new name which is the same as replacmeent 1 s old name and we must then find an order of those pairs in which for every pair, the second replacement operation occurs before the first any replacements not in a pair can be done in any order then we can do additions

Updating any data object not just at the root of a storage item is a nescessary action and needs to be considered when deciding how to implement bulk actions in the store so:

How may one perform all of the required bulk actions on root and root contained data

So our approach here changes depending on what event we are updating our instances We can do it at the time of the specification change We can choose to do a manual update of all instances to their latest version We can choose to manualy update instances of a specific specification to a specific version including rollbacks We can update instances of a specific specification to a specific version upon the data being loaded

Not that all of these methods of updating need to be supported So two methods there:

• Update instances of specific specifications to a specific specification version at an arbitrary point in time
• Update the instances of specific specifications to a specific specification version upon loading into memory, ( deserialisation| store function| surrounding code)

One option to avoid updating all data is to save a map on the store of what should be updated and then to apply that upon the next loading, for mongodb the map could be in the form of a collection The map could then be applied during deserialisation, maybe within the incrementalLoader? Maybe it could be applied in the background and at deserialisation if not finished yet One option would be to save the specification version information for the whole tree at the root upon saving which can then be interpreted by the programmatic aspect carrying out the specification update. Could this be accumulated into memory and then applied, or maybe could be done in one fell swoop, depends on the db Well doesnt the choice between how to approach this depend on specifics of the store? Why not call a function to change instances of a specification to a specific version and then the store implementation handles the update method, ( directly editing data, storing a map to apply on load, ...)

If going this route then it seems like this implementation would be seperate to other bulk action implementations? Well if going this route then it could be a command to a bulk action function but seemingly seperate to the, ( value change, value removal) ones

How one may detect the intended change by analysing the two different specifications, and failing automatic detection, what different ways one may retrieve the data needed to perform the changes

Unsure whether to perform these checks on memory representations of the specificationed class| aST reps| another format

e- name is present in to, isnt in from, hasnt been marked as a rename by user - quickMem or aST w- name is present in from, isnt in to, hasnt been marked as a rename by user - quickMem or aST q- a deletion and addition pair have been marked a name change - marked by coding body r- Two matching named attributes annotated types fail an equality check - quickMem| quickMem loaded from aST t- Two matching named attributes default valuesrfail an equality check wouldn suffice as not everything implements an equality check, we could instead compare the ast if the nodes implement an equality chekc or the string ast if they dont- quickMem aST| string aST y- function objects may implement equality checks but we arent doing anything here u- we dont do anything here i- we could do the same as t o- we dont do anything here p- we dont do anything here

When ( a name in from isnt present in to) and ( a name in to isnt present in from) then we dont know if this is a rename or a ( deletion, addition) In order to find out we have to prompt in which we must discern renames by linking deletions and additions Maybe through a linking ui

It is still important to discern whether this is an intended rename or a deletion and addition